Subject: IETF standards pursuit

From: [email-masked]
Date: Wed, 4 May 94 22:45:07 EDT

I attended the IETF BOF in Seattle and am convinced that the benefit
of having an IETF standard (versus an informational RFC) is far out-
weighed by the additional delay and effort of working it through
the IETF.  My opinion, and IBM's position, is that the RIG should
post a completed AIW standard as an informational RFC (option 2).

My reasons are as follows, in rough priority order (1 & 2 are different
facets of the same issue and are about equal):

1) Calendar time to having an implementable standard

   Options 3 and 4 both delay having a customer-accepted implementable
   standard by at least six months.  For option 3, this is because once
   we say we will take it to the IETF, we are implicitly saying that
   what the RIG produces is not final enough to be trusted as a standard.
   So many customers will not feel comfortable until IETF Proposed
   Standard status is granted.  In the absolute best case, when non-RIG
   IETF commenters say absolutely nothing (an absurd assumption),
   we will have moved "implementable standard" status from 7/94 (the
   earliest I think we can reach AP in the RIG), to 3/95 or 4/95.  This
   is an 8-9 month slip just to get to IETF "proposed standard" status
   (not to mention the 2 steps following it, which require an additional
   10 months for full standard status).

   For option 4, once again, adoption implies that the IETF is what
   counts, so we are gated by what happens there.  The earliest I can
   possibly conceive of this option working is that "proposed standard"
   status would be granted after a review period following the December
   IETF meeting in San Francisco.  With the holidays, this means 1/95
   or roughly a 6 month slip.  Again, this assumes little new discussion.
   In fact, I would expect the real dates to be a number of months further
   into 1995.

   These slips mean delayed customer acceptance of DLSw solutions, a
   longer period of confusion in the marketplace, and that instead
   of being busy full-time implementing products for our companies,
   we engineers will for many months more be attending meetings and
   doing protocol architecture.

2) Effort required by all of us to get to a standard

   The ground rules for IETF involvement are completely open mailing
   lists, equal status of AIW and IETF meetings, and decisions reached
   by e-mail.  In addition, the area director has a fair amount of power
   to influence the scope of discussion and progress of the standard.
   With these ground rules and based on the technical interchange which
   took place at Seattle, I am convinced of the following:

     - Companies with more than a casual interest in DLSw will need
       to have representatives at both sets of meetings.  At a minimum
       this means the June AIW, July IETF, October AIW, December IETF,
       February 95 AIW, and March 95 IETF.  Option 2 means only two more
       AIW meetings and that's it for the initial release of the standard.
     - There will be at least a few non-RIG participants from the IETF,
       and while very capable may lack the general SNA and connection-
       oriented background typical of RIG members.  Example from Seattle:
       objection was raised to frame-based pacing because "what if a
       client requested one byte at a time from a server?".
     - These participants, however few, will require energy from the
       rest of us to give DLSw/SNA background, and rehash old issues
       that were resolved in the RIG months ago.  Example from
       Seattle:  we should not have an independent circuit-level pacing
       mechanism but have one circuit per TCP connection and let the
       TCP flow control mechanism be the only one.
     - We will be required to address with some effort the question of
       interoperation with RFC 1001/1002 (providing a NetBIOS API within
       an IP host).  We discussed this here on this mailing list before
       the BOF and I expected we could blow it off in two minutes
       as an end station solution within an IP host that has little rela-
       tion to the problem DLSw is solving.  To my surprise, more than
       one IETF leader took the question of interoperation as a possible
       requirement to be seriously considered.  (This statement is
       based partly on hall discussions outside the BOF).  Some IETF
       participants have a business interest in RFC 1001/1002 solutions,
       solutions which become less valuable if DLSw increases the number
       of native NetBIOS end stations attached to IP networks.  I believe
       that any requirement for DLSw to interoperate would be an absolute
       disaster and kill any hope for a near-term DLSw IETF standard.

   The lack of participation on the RIG mailing lists since our
   February meeting leads me to believe that most of us are swamped
   and barely able to contribute to the RIG discussions.  Even simple
   choices seem to take weeks to make. I know that some feel new partici-
   pants could help, but my conclusion from Seattle is that going with
   the IETF will introduce more new and old issues than it will drive down
   the list we're currently struggling with.  While some positive contribu-
   tions would certainly emerge from the IETF, I do not feel they would be
   worth the price we will have to pay in time and additional effort.

3) Customer / marketplace confusion

   Either path which involves two standards bodies will continue the
   current confusion about what track we are on, what standard is the
   "real" one, and what timing a customer should expect.  It's very
   difficult to get across to the press and customers the nuances of
   how we expect the groups to work together and the different stages
   of completion of the standard(s).  I think option 2 would tremendously
   clarify the issue both for now and for the foreseeable future:  one
   working group and one specification.

4) Procedural / legal concerns about working with the IETF

   IBM legal's review of RFC 1602 (IETF standards process) has raised a
   number of concerns about its intellectual property provisions.  Louise
   referred to one but there are a few other issues.  We on this mailing
   list are engineers and are generally not worried about this stuff, but
   these issues have influenced the position IBM is taking and may be of
   concern to management and legal staff at other companies.

Now, I would like to respond to several arguments in favor of an IETF
working group with which I do not agree.

A) The people will be the same as the RIG, so the risk of extraneous
   issues or rehashed discussion is very low.

   I agree that the great majority of participants will be the same.
   However, there will be at least a few (at least the area director,
   who I think will do his job diligently), who will want to understand
   the whole design and who will raise new and possibly fundamental
   objections to how DLSw operates.  Only one or two persons without a
   direct business interest in the effort will have the ability to signi-
   ficantly delay the effort, and this concerns me.

B) IETF standard status is so valuable that it is worth any extra time
   or effort that may be required.

   In my mind the choice is between an informational and a standards-
   track RFC.  Many customers don't fully appreciate the difference.
   For those that do, let's assume for the moment we go with option 2.
   Then, if they want to route SNA and NetBIOS over IP, they will have
   a choice between:
     - a single vendor's proprietary solution
     - an informational RFC that represents the joint effort of
       every major SNA internetworking vendor
   Will customers reject the latter because it isn't a standards track RFC?
   I don't think so.  Customers accept and will continue to accept a variety
   of specifications - what counts is vendor agreement and interoperability.

   I do not agree that the industry will think we have failed if we do not
   produce an IETF standard;  the industry wants us to work together and
   produce an interoperable specification.  It is continued press and customer
   confusion about IETF v. AIW that will produce a perception of failure.

C) Having IETF participants bring new perspectives and ideas is very
   desirable.

   Ok, it is to a point.  There may be some great ideas, or technical
   problems uncovered.  But, as we all know, adding more workers late in
   a project does not speed it to conclusion.  Even in the IETF, most
   things that reach standard status have a small dedicated group of
   people driving the process. The current RIG membership has a strong
   skill base;  I don't believe we're missing any critical skills in
   TCP/IP or any other area.   So while I'm sure the IETF process would
   add some value, I think we're at the point where it is more important
   to wrap things up than it is to invite new perspectives.

In short, while I understand the arguments for IETF standard status, I think
it's time to concentrate our energies on closing out the current technical
work in the AIW.  Even after this is done, the additional cost in time, effort,
and confusion of seeking IETF standards status outweighs the benefit.

Peter Gayek
IBM Corp.